Meetings.
Talked to Rizart, he's back on August 26th (dashboards)
AM/PM: Lots of meetings.
Added unittests. Merged PR.
AM: Finishing moving stuff across, installing apps etc.
Finished classification class, moved on to adding unit tests. Merged PR.
Picked up laptop from SKAO. Began moving stuff across.
PM off.
Added a bit of architecture around build/testing process (see README) - moved Dockerfiles & modified test image to extend off dev image as there was a lot of redundancy. Made a PR.
https://gitlab.com/ska-telescope/sdc/sdc1-solution/-/merge_requests/1
Mid-way through refactoring classification code.
Decided with James not to delve into the SDC refactoring yet, wait until start of next week.
Looked over some docs instead:
Sorted out entry to site next Tuesday to get laptop.
Messaged Ghita Rahal asking her to be a guinea pig for the docs.
Did more calculations on this following Shari's comment about not being sufficient. Checked against theoretically expected. Will need to use a different protocol because of TCP window sizes.
Finished first draft.
Ported rucio-client repo to ESCAPE-WP2 instance and created org on dockerhub (projectescape) to allow automated build once repo has authorised access.
Retro and planning meeting for sprint 4 in the afternoon.
Looked over ASKAP instance data throughput issue. Suggestions in #team-planet included using a diff protocol, e.g. rsync, and also iperf. Iperf isn't possible without installation at both sites + open ports.
Did a rough calculation re: latencies.
Looked at moving SDCSS to GKE so accessible to science team.
Ops coffee and standup didn't leave much time to do anything as PM off.
Did a small test + spoke to Philippa about BITPIX=32 cubes as possible solution to checksum mismatch
Found two test endpoints in Rizart's fts-analysis etc/example.json:
I can now a) create files and transfer to an endpoint, e.g.
$ python toolkit/gfalcp-urandom-files.py
-durl xroot://dcache-se-doma.desy.de/escape/wp2_rucio_testbed/desy_dcache/fts-analysis-tests-2/
-mb 1 -n 1 -tdir /tmp/ -sti 1
b) create a job:
$ python generate-submission-file.py
-durl xfer.cr.cnaf.infn.it:8443/escape/rucio/cnaf_storm/fts-analysis-tests
-surl dcache-door-doma01.desy.de:2880/escape/wp2_rucio_testbed/desy_dcache/fts-analysis-tests
-p davs -o submission-files/ -mb 1 -n 1 -sti 1 -up 1
and c) submit a job:
$ python fts-benchmark-job.py
-i submission-files/dcache-door-doma01_xfer_davs_1files_1mb_subm_file.in
-o data_folder -checksum=none
the creation and submission of a job can be done via json (see /etc/example.json) using the benchmark.py script.
Note that the files for the job must already exist at the start endpoint.
Made a Dockerfile and submitted PR.
Mostly meetings in the morning.
Have now received access grant for escape VO.
Tried a:
$ voms-proxy-init --voms escape
but it returned an error:
WARNING: VOMS AC validation for VO skatelescope.eu failed for the following reasons:
LSC validation failed: LSC file matching VOMS attributes not found in store.
AC signature verification failure: no valid VOMS server credential found.
Turns out that your trust anchors need to be located in a subdir of /etc/grid-security/vomsdir
with a name corresponding to their (aliased?) hostname, i.e. for escape:
[eng@c2c7e3e9aa2a ~]$ ls -R /etc/grid-security/vomsdir/
/etc/grid-security/vomsdir/:
escape
/etc/grid-security/vomsdir/escape:
voms-escape.cloud.cnaf.infn.it.lsc
Now running a gfal-ls works:
[eng@c2c7e3e9aa2a ~]$ gfal-ls gsiftp://dpmhead-trunk.cern.ch/dpm/cern.ch/home/dteam/
1
100M
10MB
1112121
On destroying the proxy:
$ voms-proxy-destroy
and reinitialising, I am no longer able to gfal-ls.
Changing the protocol seems to work:
$ gfal-ls davs://dpmhead-trunk.cern.ch/dpm/cern.ch/home/dteam/
List of protocols here: https://dmc.web.cern.ch/projects/gfal-2/documentation
Can't seem to gfal-copy still.
Understand the basic functionality behind the SDC1 code following meeting with Alex & James.
Looked over James' framework & made a few minor suggestions.
From Ben - GCD instance here: https://console.cloud.google.com/kubernetes/list?project=ska1-simulations-270612&authuser=1
Spent the morning looking at X509 authentication for the Grid.
Useful guides:
Needed to add .p12 grid certificate to browser:
Settings > Privacy and Security > Security > Manage certificates
and then register individually for each VO:
To access/move files, a VOMS proxy must be generated first through:
$ voms-proxy-init --voms [VO]`
where VO is the virtual organisation name.
Currently waiting on escape VO access being granted. Still not clear which end points will be available after this.
Dockerised Rizart's fts-analysis, but can't check without access to escape VO.
Can build image using:
$ docker build . --tag fts-analysis:latest
and run the container using:
$ docker run -it -v ~/ESCAP/ESCAP-151/fts-analysis/:/home/eng/fts-analysis-devel -v ~/.globus:/home/eng/.globus --name fts-analysis fts-analysis /bin/bash
being sure to mount the grid usercert/key. Mounting fts-analysis-devel allows access to the code from outside the container using e.g. VSCode.
Talked to Philippa & Anna about the SDCSS and SDC2 skeleton. Requested access to google compute from Ben to spin up an instance of the system for testing.
James has prepared a document about getting started with the skeleton.
Had to remake VM after lost the GDM.
Tried to get my head around the workflow for Rohini's deployment of the SDC2 cube generation.
There are two images on the IRIS openstack currently: testsdc2sim and skascience01. The former is used as compute to construct the cube, the latter is basically a staging area.
To get to the former, you need to ssh to the externally exposed aeneas-ui machine, then on to the testsdc2sim instance using the internal network IP. The latter is available via an externally accessible IP.
The staging area is used to hold the input atlas and latest version of Philippa's pipeline (via a daily cronned git pull).
From the compute machine, you need to download the sdc2-simulation-environment repo (https://gitlab.com/ska-telescope/sdc/sdc2-sim-environment/) and follow the instructions in the README.
To run the pipeline:
ini\*.ini).DownloadPrerequisites.sh) otherwise you get a FileNotFoundError: [Errno 2] No such file or directory: '/home/atlas/prepared_blank_cubes/H08cr_rotated_shrunk.fits' error.Checked Philippa's attempted bug fix re: cube checksum mismatches. Didn't work.
Started to create a container for fts-analysis. Trying to auth using the grid certificate to test.